Optical control plane implementations provide automated setup and control of services. Advantageously, control planes offer multi-vendor and inter-domain inter-working, enhanced service offerings such as Ethernet over SONET/SDH or Optical Transport Network (OTN), end-to-end service activation, cross-domain provisioning of switched connection services, fast mesh restoration, and the like. Traditionally, creating traffic paths through a series of Network Elements (NEs) has involved configuration of individual cross-connects on each NE. Control planes allow a user to specify a start point, an end point, and bandwidth required, and an agent on the Network Elements allocates a path through the network, provisioning the traffic path, setting up cross-connects, and allocating bandwidth from the paths for the user requested service. The actual path that the traffic will take through the network is not specified by the user.
Several control plane standards for optical networks exist including ITU-T Automatically Switched Optical Network (ASON), IETF Generalized Multi-Protocol Label Switching (G-MPLS) also known as Automatic Switched Transport Network (ASTN), and Optical Internetworking Forum (OIF) User-Network Interface Signaling Specifications (UNI) and Inter-Carrier Network Interface Signaling Specification. ASON specifications generally define an optical control plane communication framework. G-MPLS defines control plane discovery, routing, and signaling protocols. OIF UNI/E-NNI specifications define protocol extensions for multi-vendor interoperability.
The requirements for automatically switched optical networks (G.ASON) are outlined in ITU G.807/Y.1302. The control plane functions for the G.ASON network are defined for Signaling and Related Interfaces, Routing Connection Admission Control (CAC), Naming and addressing, etc. Conventionally, implementation of these functions, particularly routing and connection admission control, has typically been handled as a serial process. For example, current software architectures for optical switches are designed for a single processor system. These include individual software managers that handle functional areas. For instance, a routing protocol (e.g., Optical Signaling and Routing Protocol (OSRP)) and call control is handled by one process called a Call Handler Agent. This agent receives all requests for creation, failures, restoration, routing, and performs the appropriate actions to handle them.
Current processor development is running up against physical limitations. This is preventing further performance enhancements to a single processor. The hardware industry is therefore moving to multiple cores running together on a single processor to get continued performance improvements. Carriers and other service providers are continuously in the midst of major network expansions adding more and more optical network elements. Their networks are often dependent on G.ASON architecture such as OSRP to manage and protect their traffic. Disadvantageously, in many cases, carriers and other service providers are approaching the scalable limits of conventional software and hardware architecture for control plane processors.
The approach using a single call handler agent works fine with a single processing core. The monolithic task runs on the processor and maximizes central processor unit (CPU) utilization during failure recovery situations. An Optical Switch can control the different functional areas by setting priorities to tasks that determine which task is the most important. This task then gets to run based on it priority. However, this implementation does not scale, and is a significant constraint on network growth.